Apparently the linux test-runners are down.

The scope-hoisting tests are using experimental JS in some tests so babel is complaining. I'll try to find some time soonish to dig deeper into fixing that.

I just hope nobody publishes code with unstandardized JS, otherwise this would be a breaking change.

@fathyb you have any idea if this would affect scope-hoisting a lot? And whether this PR is even a good idea at all.

As far as scope-hoisting goes I think it'll be okay as soon as it doesn't add the commonjs transform.
For the rest I'm not really sure, it makes sense to me but I'm not sure of the consequences. The tests are coming from #559, pinging @devongovett for advice!

Hmm I don't know that we want to change this. We currently assume that node_modules is already compiled by default, unless a browserslist or engines.node value indicates otherwise. Without either of those keys in package.json, I'm not sure how we could assume anything about how the code was written other than that it is already compiled. Turning on babel for all node_modules will slow down Parcel by a ton I would guess.

@devongovett originally thought the logic was assuring the entire bundle matches a certain browserslist. This is the only way I could think of achieving that as defining a browserslist or engines field in a package is optional.

Perhaps we could allow some way to enable this, for people who really want full browser compatibility?

Not sure if this is a good idea or not, seems to break the moment anything has unstandardised JS.

node_modules shouldn't contain non-standard code for sure, but historically node_modules has been ES5 as well, meaning pre-babelified. This ensures the most interoperability between tools. Parcel takes this as the default, and assumes that if no other information is specified, the code is already pre-compiled to ES5. However, people are starting to target newer versions of node/browsers in their node_modules, so we added support for specifying that in engines.node and browserslist fields. When those are specified, and they target higher versions than the app, we run babel over the module. Otherwise, babel is not run over node_modules.

Alright so people should just change their package.json, got it.

I just stumbled upon are-you-es5 which tries to parse each dependency with acorn to tell if it is valid es5 or not. I guess Parcel could check dependencies before bundling or the generated bundles with this or a similar approach and transpile them in case they do not fit the target environment. Maybe behind a flag for performance reasons.

Update:

es-check does the same but is more popular.